COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002						July 18, 1974
C00022 ENDMK
C⊗;
					July 18, 1974

This document describes the new User Disk Pack software service.
Our former six single density disk drives have been converted
to four double density drives, three of which are used for the
main file system and the fourth for user packs.  (The timesharing
system can be configured for more than one user pack drive, and
for any combination of single or double density drives.)

The one, double density UDP drive presently available is device
UDP1 (not UDP0 as in the former system.)

The old UDP service did not provide a file structure for the user
pack--input and output operations referred to absolute track
addresses on the pack, and the allocation of tracks to files was
the responsibility of the user program.  This service is described
in Section 13.9 of the UUO Manual (pp. 165-6).  User packs can
still be used in this way, if desired; the only difference to a
user program is that a double density pack has =15199 usable tracks
versus =7599 for single density.

However, the (preferred) new UDP service provides a file structure
which acts just like that of the main file disk: it has user file
directories, file protection codes, etc.  just like the DSK device.
Thus, programs written to use DSK files can operate directly on
UDP files by simply INITing a UDP device instead of DSK.  (This can
be accomplished without modifying the program by ASSIGNing the UDP
with logical name DSK, as long as the program is using only UDP
files.)  Before a user pack can be used in this new way, it must
be initialized.  This is done for you by a system programmer.

The COPY program, which formerly simulated a file structure on
UDPs using the old UDP service, now uses the new UDP service
and treats the UDP just like DSK.  The ZERO program, which was
formerly used to initialize the UDP for use with COPY's file
structure format, still does that and should NOT be used to
format a pack for the new file structured service!

The old UDP service is faster than the new; this may be important
to some users with real-time applications.  Old mode UDP
operations are given a higher priority in the monitor; no extra
disk operations are necessary for file directory access; and
most importantly, transfers of more than one track are done in
one single operation in the old service routine and are therefore
more likely to succeed without wasting a disk revolution.

To distinguish between the two ways of using a user pack, you must
enter a monitor ASSIGN command for the UDP before your program can
use it.  This command has an extra parameter for the UDP, which
specifies old or new service, and also whether or not other jobs
may use the pack at the same time.  The commands are:

	ASSIGN PUBLIC UDP1
	ASSIGN PRIVATE UDP1
	ASSIGN OLD UDP1

Only enough of the mode parameter to identify it uniquely need
be typed.  If no mode is typed, the default is initially PUBLIC,
but typing a second ASSIGN command while the UDP is still
assigned without a mode leaves the mode unchanged.

Although there is only one UDP drive, the monitor treats UDP as
a multi-unit device name like MTA.  Thus, ASSIGN UDP will
result in the message UDP1 ASSIGNED AS UDP from the monitor.
However, unlike all other multi-unit devices, the UDP is
sharable.  For this reason, ASSIGN UDP will fail if the UDP is
already assigned by any job, including your own, whereas
ASSIGN UDP1 will succeed if the UDP is already assigned by your
job, or by another job in PUBLIC mode.  Also, as with DSK, the
UDP can be assigned with several logical names at once by using
several ASSIGN commands.  Note, however, that the command
DEASSIGN UDP1 will only deassign one such logical name; the
DEASSIGN command with no arguments will relinquish all device
assignments.

OLD mode implies private; that is, when the UDP is assigned in OLD
mode, no other job can use that drive until it is deassigned.
If you assign a UDP in OLD mode and later want to use it in new
mode, you must first deassign it, and it must not be INITed by
your program.  Note: A pack which has been formatted for new
mode use may be assigned in OLD mode, but in this case you will
not be allowed to write on the pack.  Thus, files on a new type
UDP cannot be destroyed by accidental OLD mode use.

A new mode pack, like the main file system, is capable of being
shared by many jobs.  The user who mounts and assigns the UDP
can choose not to allow access by other jobs, by assigning it
as PRIVATE.  The mode may be changed between PUBLIC and PRIVATE
by repeating the ASSIGN command with the appropriate argument,
except that the mode cannot be changed from PUBLIC to PRIVATE
if more than one job is using the pack.  A pack which has not
been initialized for new mode must, of course, be assigned in
OLD mode.

Note that you MUST give an assign command before your program
can use a UDP!  (This is not presently true for any other
device.)  This holds true even if another job has already
assigned the UDP in PUBLIC mode.

[Note: Elsewhere in system documentation, the distinction is
made between "sharable" and "non-sharable" devices.  This is
not the same as "public" vs. "private"; on a non-sharable
device, only one transaction can go on at a time, i.e., the
device may only be INITed on one channel at a time.  When a
UDP is used in PRIVATE mode, only one job may use it, but
that job may read and write many files simultaneously on
different channels. The UDP is always sharable in that sense.]

The UDP is the only removable storage unit which is sharable.
This introduces the danger of one user dismounting a UDP which
is still being used by another job.  To help prevent this,
when a DEASSIGN command is given for the UDP, the monitor
types out one of these messages:
	DEVICE UDP1 MAY BE UNLOADED
	DEVICE UDP1 STILL IN USE - DON'T UNLOAD
Although you must assign the UDP before your program can use
it, it is possible to interrupt a program and deassign the
UDP while it is still INITed by your program.  In this case,
you will get the STILL IN USE message.  When the program
releases the UDP (by RELEASE, EXIT, or RESET UUOs), you will
again see whichever message is appropriate.

If you have assigned the UDP and want to dismount one new
format pack and mount another, you must DEASSIGN and ASSIGN
the drive.  (All users must RELEASE and DEASSIGN the UDP
before the pack can be changed.)  If this is not done, all
attempts to read or write files on the new pack will get
BAD RETRIEVAL errors.

Except for the new ASSIGN command which must be used, the
OLD mode use of the UDP is essentially unchanged.  Programs
which worked before should still work; of course, more space
is available with the double density packs.

A new format pack still has the password block in the last
track, as described in the UUO manual.  This password will
be required to establish new user file directories on the
pack.  There is a monitor command, UDPUFD, for manipulating
file directories of user packs.  To use it, first assign the
UDP and mount the pack.  Then give the command
	UDPUFD PRJ,PRG
to create or modify a PRJ,PRG directory on the UDP.  If the
directory does not already exist, you will be asked to type
the pack password; if it does, you will be asked for the
password for that directory, if there is one.  You are then
allowed to set the directory's password and file protection
parameters, just as in LOGIN PRJ%PRG for the system file
disk.  If the directory exists but is empty, you are given
the chance to have it deleted.  The command "UDPUFD 1,1"
will let you change the pack password if you know the old
password.  The UDPUFD command runs a privileged program in
your core image.

As on the file disk, passwords and file protection are
intended for accident prevention, not secrecy.  UDP passwords
are even easier to circumvent than ordinary ones.  Be warned.

The swapping/scratch pack, which is an OLD format pack for
general use, has the special password "*SWAP*".  This
password is specially recognized by the monitor, and has
the following special properties: a blank (zero) password
will be accepted in an old-mode ENTER for this pack, but
it is impossible to change the password (RENAME will fail).
This password should not be used for any other pack.

In addition to the password, a new format pack includes a
"volume ID" which is written on the pack label.  This ID
is also included in the retrieval blocks for every file on
the pack, and cannot be changed by the pack user once files
have been written on the pack.  The monitor RESOURCES command
types, for each UDP, whether it is FREE, PUBLIC, PRIVATE,
or DETACHED FROM SYSTEM.  If a file-structured pack is mounted
on the drive, it will type the volume ID and the number of
free tracks on the pack, as it does for DSK.  (This information is
not available to the monitor until an actual I/O operation
is performed on the pack, so a RESOURCES command given just
after ASSIGNing the pack will not have it.)

The information above is sufficient for most users of UDPs.
What follows is some detailed descriptions of changes in UUOs
related to the UDP service, which should not affect most programs.
The following assumes some degree of sophistication in your
understanding of the monitor's innards.

The DEVCHR UUO for a UDP returns in bits 18 and 19 the OR of
the ASSCON and ASSPRG bits in all DDBs for that UDP.  Bit 12,
which indicates if the device is available to your job, is on
if the UDP is unused, public, or owned by your job.  The DVDSK
bit (bit 1) will be on, as well as DVUDP (bit 2), if the UDP
is assigned in new mode or is unassigned, but will be off if
the UDP is assigned in OLD mode.  For a more useful accounting
of the ASSCON and ASSPRG status of the UDP, see DEVUSE below.

Several new bits are used in the DEVUSE UUO to report on the
UDP's status:

Bit	Value		Meaning
---	-----		-------
 3	40000,,0	ASSIGNed by this job
 4	20000,,0	INITed by this job
 5	10000,,0	ASSIGNed by some other job
 6	 4000,,0	INITed by some other job
 7	 2000,,0	PRIVATE (or OLD)

Zero is returned for an unused UDP.  If bits 12:17 are zero but bit
7 is one, the UDP is detached from the system; by the privileged
DETACH command if bit 6 is off, or for swapping use because the
Librascope disk is down if bit 6 is on.  Bits 12:17 will be zero
with bit 0 one if the UDP is assigned as PUBLIC.  (To distinguish
between PRIVATE and OLD modes, check the DVDSK bit from the DEVCHR
UUO, as described above.)

Since the distinction between old and new UDP service is made by
the required ASSIGN command, the previously advertised use of the
100 mode bit in the INIT to select old mode is inoperative.

The DSK MTAPEs are also available to new mode UDP users, with the
following differences in some privileged MTAPEs:

The absolute read and write MTAPEs take track addresses relative
to the UDP's track 0, and limited to the last track of the UDP.
(The DSK version can still refer to the entire 3330, including
UDPs.)

The SATID for a UDP is its volume ID, as described above, in SIXBIT.
It is never changed once the pack has been formatted.  The password
block of the UDP is permanently marked in use in the UDP's SAT.
User packs are initialized with the [1,1] password the same as the
UDP password in the last block.

Two new MTAPEs were created primarily for UDPs but also work for DSK:
	MTAPE CHN,[	'GODMOD'
			22
			ADDR	]
stores the number of free tracks on the structure (as typed by the
RESOURCES command) in location ADDR.  This is the number of tracks
after which new ENTERs are not allowed, =200 tracks before the
structure is actually full.
	MTAPE CHN,[	'GODMOD'
			23
			ADDR	]
stores the SATID of the structure in location ADDR.

The privileged DETACH command for a UDP does not create a DDB.
Instead, it sets UDPOWN for the drive to zero, and leaves
UDPCNT zero.  ATTACH UDP1 restores UDPOWN to -1, and does not
leave the UDP assigned to your job.

The updating of reference date for UDP files is normally done,
as on the file disk, but if the UDP is writelocked, the
retrieval is not updated and no error message is given.  Thus,
the reference date may not be completely up-to-date.